FAO Emilio #4
Closed
FAO Emilio #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note! There are a lot of assumptions and bad coding ahoy, review thoroughly and expect not to be complete! This version has most of the core files updates to support the LPC1788 and appears to compile with both mbed python scripts and Keil uVision set to use the ARM-EABI-NONE- toolchain (although only with a lot of wrestling), however it fails the basic test with Keil (Hard Fault when calling wait_usec), I suspect this is an issue with the JTAG interface as it only simulates Timers 0 and 1, whereas wait uses Timer 3. The binary compiled with the mbed python scripts just appears to hang doing nothing. Hopefully Emilio and the team can make more sense of this. - Jason
|
Jason Gaunt wrote:
OK, closed. :-) |
PrzemekWirkus
added a commit
that referenced
this pull request
Feb 26, 2015
Synd with master (February)
SeppoTakalo
pushed a commit
that referenced
this pull request
Nov 9, 2016
Update dependencies and remove compiler warnings
donatieng
referenced
this pull request
in donatieng/mbed-os
Mar 1, 2018
Palsm cordio implementation: skeleton
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 25, 2018
Add default pin macro names and default pins on select set of boards
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 25, 2018
Add macros for default pin names
bcostm
pushed a commit
to bcostm/mbed-os
that referenced
this pull request
Sep 13, 2018
NUCLEO_H743ZI: analogin improvements - 16b feature confirmed by IntroPack
naveenkaje
pushed a commit
to naveenkaje/mbed-os
that referenced
this pull request
Jan 14, 2019
Fix SoftDevice configuration on NRF52_DK
Closed
geky
added a commit
to geky/mbed
that referenced
this pull request
May 30, 2019
option to pass I2C object
hugueskamba
referenced
this pull request
in hugueskamba/mbed-os
Jul 2, 2019
drivers/Ethernet, and anything Ethernet-related in the “HAL” region has
never been used in Mbed OS 5. Ethernet is not provided like
other core things such as serial.
So drivers/Ethernet.h, drivers/Ethernet.cpp and hal/ethernet_api.h,
and anything referring to them is obsolete.
From 5.0-5.8, Ethernet drivers were written natively as lwIP or
Nanostack drivers, and attached via their native APIs. No Mbed OS APIs
were involved for driver attachment.
Since 5.9, Ethernet drivers are provided by a class derived from
`EMAC`, and is attached to lwIP or Nanostack.
The above assume Ethernet drivers that send and receive Ethernet frames,
in other words it assumes it uses an on-board IP stack. If the interface
has an off-board IP stack, then a custom driver needs to derive from
`EthInterface` or `WifiInterface` and implement the complete socket API
for them.
Applications can use various degrees of abstraction by designating
particular classes:
* NetworkInterface - any interface type
* EthInterface/WifiInterface/MeshInterface/CellularInterface –
specific interface type, no particular implementation
* EthernetInterface – Ethernet using on-board stack, default EMAC
* EthernetInterface<EMAC> - Ethernet using on-board stack and
particular EMAC
ESP8266Interface/BG96CellularModem – Particular network interface
The top couple have static “get_default_instance()” methods to locate
an appropriate interface for the current target. Or applications can
nominate their driver specifically using the lower forms.
“EthernetInterface” is a concrete implementation of the abstract
“EthInterface”, it means “Use default onboard stack with default EMAC
driver, defaults selected by get_default_instance”.
That’s only half an abstraction – really portable apps should be saying
“EthInterface::get_default_instance” (not caring about onboard or
offboard), or “NetworkInterface::get_default_instance” (not caring about
Wifi or Ethernet).
hugueskamba
referenced
this pull request
in hugueskamba/mbed-os
Jul 3, 2019
drivers/Ethernet, and anything Ethernet-related in the “HAL” region has
never been used in Mbed OS 5. Ethernet is not provided like
other core things such as serial.
So drivers/Ethernet.h, drivers/Ethernet.cpp and hal/ethernet_api.h,
and anything referring to them is obsolete.
From 5.0-5.8, Ethernet drivers were written natively as lwIP or
Nanostack drivers, and attached via their native APIs. No Mbed OS APIs
were involved for driver attachment.
Since 5.9, Ethernet drivers are provided by a class derived from
`EMAC`, and is attached to lwIP or Nanostack.
The above assume Ethernet drivers that send and receive Ethernet frames,
in other words it assumes it uses an on-board IP stack. If the interface
has an off-board IP stack, then a custom driver needs to derive from
`EthInterface` or `WifiInterface` and implement the complete socket API
for them.
Applications can use various degrees of abstraction by designating
particular classes:
* NetworkInterface - any interface type
* EthInterface/WifiInterface/MeshInterface/CellularInterface –
specific interface type, no particular implementation
* EthernetInterface – Ethernet using on-board stack, default EMAC
* EthernetInterface<EMAC> - Ethernet using on-board stack and
particular EMAC
ESP8266Interface/BG96CellularModem – Particular network interface
The top couple have static “get_default_instance()” methods to locate
an appropriate interface for the current target. Or applications can
nominate their driver specifically using the lower forms.
“EthernetInterface” is a concrete implementation of the abstract
“EthInterface”, it means “Use default onboard stack with default EMAC
driver, defaults selected by get_default_instance”.
That’s only half an abstraction – really portable apps should be saying
“EthInterface::get_default_instance” (not caring about onboard or
offboard), or “NetworkInterface::get_default_instance” (not caring about
Wifi or Ethernet).
evedon
pushed a commit
to evedon/mbed-os
that referenced
this pull request
Jul 5, 2019
Add support for width specifiers
linlingao
added a commit
to linlingao/mbed-os
that referenced
this pull request
Jul 12, 2019
Add stubs to get blinky to build
evedon
pushed a commit
to evedon/mbed-os
that referenced
this pull request
Jul 15, 2019
Add support for width specifiers
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 4, 2019
Refactor codebase based on feedback from initial users
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note! There are a lot of assumptions and bad coding ahoy, review
thoroughly and expect not to be complete!
This version has most of the core files updates to support the LPC1788
and appears to compile with both mbed python scripts and Keil uVision
set to use the ARM-EABI-NONE- toolchain (although only with a lot of
wrestling), however it fails the basic test with Keil (Hard Fault when
calling wait_usec), I suspect this is an issue with the JTAG interface
as it only simulates Timers 0 and 1, whereas wait uses Timer 3. The
binary compiled with the mbed python scripts just appears to hang doing
nothing.
Hopefully Emilio and the team can make more sense of this.